Skip to main content

Full text of "The Interface message processor for the ARPA computer network"

See other formats

Report No. 2059 
October 1970 
1 July 1970 to 30 September 1970 
Submitted to: 
Advanced Research Projects Agency 
Washington, D.C. 20301 
Attn: Dr. L.G. Roberts 
This research was supported by the Advanced Research Projects 
Agency of the Department of Defense under Contract No. DAHC-15- 
------------------------------<page break>-----------------------------
Report No. 2059 
October 1970 
1 July 1970 to 30 September 1970 
Principal Investigator: 
Mr. Frank E. Heart 
Telephone (617) 491-1850, Ext. 470 
Sponsored by 
Advanced Research Projects Agency 
ARPA Order No. 1260 
Contract No. DAHC15-69-C-O179 
Effective Date: 2 January 1969 
Expiration Date: 31 December 1970 
Contract Amount: $2,195,736 
Title of Work: IMP 
Submitted to: 
Advanced Research Projects Agency 
Washington, D.C. 20301 
Dr. L.G. Roberts 
Telephone (202). 697'8654 
------------------------------<page break>-----------------------------
, Report No. 2059 
Bolt Beranek and Newman Inc. 
Section 1. 
INTRODUCTION ................. 1 
TERMINAL IMP ................. 5 
HOST PROTOCOL ............... 11 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
This Quarterly Technical Report No. 7 describes several 
aspects of our technical progress on the ARPA Computer Network 
during the third quarter of 1970. 
▀ During this period, we installed IMPs No. 10 and No. 11 
at Lincoln Laboratories and Stanford University, commenced 
experimental testing with 230.4 kilobit/sec circuits in the 
test cell at BBN, and completed retrofits of new control panels 
and auto restart circuitry. 
▀ We developed a new version of the operational IMP pro- 
gram (IMPSYS 24) for release in November 1970. The organization 
of the IMP program has been substantially changed from the pre- 
vious operational program to allow a large number of modifica- 
tions to be efficiently incorporated. This activity is described 
in Section 2. 
▀ A primary development effort during this quarter has been 
directed toward the preliminary design of the terminal IMP. 
Initial logic design has been completed for a multi-line con- 
troller that will handle up to 64 asynchronous or synchronous 
terminal devices, and all standard codes and speeds. In ad- 
dition, we have produced preliminary coding of the inner loop 
of the terminal IMP program. This effort is described in Section 3. 
------------------------------<page break>-----------------------------
Report No, 2059 
Bolt Beranek and Newman Inc. 
▀ The Network Control Center has now been in operation for 
over three months. This effort has progressed particularly 
smoothly. A mini-Host was constructed in the prototype IMP for 
use by Network Control Center personnel in obtaining hourly 
summaries of network performance. A sample of this summary 
information is presented in Section 4. 
▀ We have continued to participate in discussions of Host 
protocol. Several modifications have been made to the IMP pro- 
gram to conform with the Host protocol. 
lated an alternate Host protocol scheme. 
described in Section 5. 
In addition, we formu- 
This activity is 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
During this quarter, the operational IMP program was ex- 
tensively revised. Revision was necessary to the efficient 
incorporation of many new system features and to modifications 
in the new version of the IMP Program (IMPSYS 24)', scheduled 
for release in November. 
New system features include a single line test message 
that each IMP transmits to its neighbors at half-second inter- 
vals. All routing, HELLO, and I HEARD YOU information is com- 
bined and transmitted in this single message. Previously, 
these three line test messages were transmitted separately. 
The quality of a given line is now measured by the number of 
line test messages which fail to get through on that line in a 
time interval of approximately one minute. 
A remote crosspatching feature was incorporated to allow a 
selected interface or modem to be looped under control of the 
operational IMP program. This capability enables the Network 
Control Center to locate accurately the source of most field 
problems. IMP personnel can now isolate a faulty communication 
line, a faulty modem, and most hardware interface problems 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
directly from the Network Control Center. However, the on-site 
assistance of Honeywell or telephone company personnel is still 
.required for subsequent diagnosis and repair. 
The long-term timeout period was reduced from 15 minutes 
to one minute. This reduction involved careful attention to 
timing in each of the major system routines to insure that the 
sequence of time-out mechanisms involving one or more IMPs 
would be executed in the proper order. 
Approximately a hundred minor revisions have been made to 
the IMP program. For example: 1) partially reassembled mes- 
sages are now discarded when their source goes dead; 2) the Host 
can no longer use all the iMP's buffers by causing error mes- 
sages to be generated but not accepting them; 3) an IMP may be 
induced to reload from a specific line instead of a random line; 
4) the IMP number is not changed when an IMP is reloaded with 
its memory protect switch in the off position 5) the Host 
routines may be put in a hardware test mode by the control 
center to facilitate Host debugging; 6) all phone lines are 
initialized to be down rather than up. 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
We have begun to work on the design of a terminal IMP that 
will serve the dual function of an IMP and a erminal device 
handler. It will provide a capability for direct connection 
of terminals into the net. Specifically, the terminals need 
not be connected to a Host computer; but, rather, they may 
access any remote Host computer via the terminal IMP and the 
A brief description of our initial design for the terminal 
IMP and its device handling capabilities, as presently envis- 
ioned, is given below. Built into the terminal IMP will be a 
multi-line controller capable of handling up to 64 terminal 
devices. The controller provides all of the logic for assembly 
and disassembly of characters and for transferring characters 
into and out of the IMP's memory. Both synchronous and asyn- 
chronous lines can be handled, the practical distinction being 
whether or not the controller must provide the clocking signal. 
All input characters must be of "asynchronous format" in that 
both start and stop bits are required by the terminal IMP. Out- 
put characters will also be provided in "asynchronous format" 
to each terminal on either synchronous or asynchronous con- 
nections. Character sizes of from five to eight bits can be 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Neeman Inc. 
handled. The program will be able to set b. oth the character 
size and speed for each device, thus enabling the program to 
determine the type of terminal connection and permitting a 
number of options, such as a dial-up capability, to be provide. 
A terminal device may be operated on input or output at 
speeds up to and including 19.2 kilobits/sec. However, no more 
than 10 devices may have speeds exceeding 2400 hits/second; 
the remaining devices must all be operated at speeds of 2400 
bits/second or less. The oerall bandwidth of the terminal IMP 
for combined input and output is limited by the programUs capa- 
bility to process characters. Present estimates are that the 
terminal handling bandwidth will be about 100 kilohits/second. 
The interface to the terminals will conform to the RS232 
standard. A terminal device may be directly connected to the 
multi-line controller or a device may be remotely connected via 
a modem. Several standard modem types will be available on 
cards that can be housed in the terminal IMP enclosure. 
We have begun preliminary work on the program design for 
the terminal IMP. Our initial estimates, based on the Honey- 
well H-316, indicate that the inner loops of both the input 
and output sections require about 50 cycles to process a 
------------------------------<page break>-----------------------------
Report No. 
Bolt Beranek and Newman Inc. 
character. The central task on output is to handle the trans- 
fer of packed characters from a single buffer one at a time 
out a multiplexed DMC channel. The central task on input is 
to pack input characters and to monitor the input for mode 
changes. The programs must also provide echoing, do character 
conversion if needed, and must process user-specified infor- 
mation such as the message destination. 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
During the last quarter, the Network Control Center (NCC) 
maintained the ARPA Network, scheduled time as appropriate fo 
network maintenance and testing, and coordinated actiżities 
among Honeywell, the telephone company, and the sites. 
A standard procedure was developed for site personnel to 
report trouble or repairs directly to the control cente. In 
most instances, requests for use of the IMP to perform main- 
tenance or testing have been easily coordinated through the 
control center. At any given time, the NCC has fairly complete 
knowledge of the current and expected state of the network, and 
as such is usually able to deal straightforwardly with most 
problems that arise. 
Status information on the lines and IMPs in the net is 
printed on the iMP teletype at BBN as received from each IMP 
in the net. The NCC has been using this information as a 
standard reference for monitoring network status. 
The Network Control Center has also implemented a program 
to provide hourly summaries of network performance. This pro- 
gram has led to a simplification in the procedures for monitor- 
ing the net, has improved upon the capabilities for detecting 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
status changes, and has provided a more convenient means of 
recording information. We plan to improve the capabilitiea of 
this program during the next quarter. 
A sample of the summary output is illustrated below: 
DAY 2 4 
****::::****IMP :::::::::::::::::::::::::: 
1 2 3 4 5 6 7 8 9 1 11 12 
1 2   I 1 i i i 1 1 i * * i * 
.............. :::"LINE ::::::********** 
1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 
12 1 1 1 1 1 I 1 I 1 1 i I I i 1 
**********LINE ERRORS********** 
TOTALS *(+/-)* 
------------------------------<page break>-----------------------------
Report No. 2059 
Bolt Beranek and Newman Inc. 
A mini-Host system was implemented in the prototype iMP in 
which this program and several other useful programs are run. 
The prototype IMP is currently conne6ted to BBN's regular IMP. 
The operational IMP program at BBN has been temporarily patched 
so that all messages to BBN's teletype are copied and passed to 
the prototype, which in turn examines each received message and 
processes only the trouble reports. 
Every hour on the hour, a summary report is printed show- 
ing: 1) the status of each IMP in the net at the beginning of 
the hour and each subsequent change in status; 2) similar 
status information for all lines in the net; and 3) a cumulative 
sum of line errors for each line during the hour. 
In the current version of the program, an IMP is said to 
be up only if a status report has been received from the IMP 
within the last 20 minutes. A line is said to be up if the IMPs 
at both ends of the line report it to be up. 
":" 1 0 
------------------------------<page break>-----------------------------
'Report No. 2059 
Bolt Beranek and Newman Inc. 
Two new control message types, cease sent and retract cease, 
were added to the IMP/Host Protocol to conform with the Host-to- 
Host Protocol. The cease sent is presented to the Host whenever 
a cease on link RFNM is constructed. The retract cease message 
negates the effect of a cease message if it can. 
To assist the Hosts in their debugging efforts, we have 
modified the IMP program to discard any Host messages sent on a 
blocked link. A blocked link error message is returned to the 
Host. Previously, the message was not discarded, and the Host 
line was hung for 15 minutes in this situation. One consequence 
of this change is that messages sent on blocked links from the 
real Host will be discarded to unbiock the Host interface; mes- 
sages sent on blocked links from a Fake Host will hang the Fake 
Host until the link is unblocked. 
In Network Working Group 67 a change to the IMP program 
was proposed that would have resulted in the leader of a message 
being sent as a separate message before the text in all communi- 
cation between the Host and its IMP. We believe that this change 
could have simplified the Host message handling procedures. 
Although this proposed change met with general approval, it 
------------------------------<page break>-----------------------------
'Report No. 2059 
Bolt Beranek and Newman Inc. 
would have introduced a negative transient in some Host efforts 
to achieve timely use of the net. We are therefore no longer 
considering this change at this time. 
A Host protocol document entitled "Interprocess Communica- 
tion in a Resource Sharing Network" was generated by David Walden 
in an effort to provide some fresh insights into this area. The 
scheme described in this document is philosophically different 
from the Protocol currently under implementation for the ARPA 
In this protocol scheme, connections are non-permanent 
entities that are established each time a message is communicated 
between processes. Each message carries a complete set of 
identification information, including the receive and send socket 
pair. A rendezvous scheme, that permits dynamic reconnection to 
occur, is an intrinsic part of the basic communication procedure. 
Although this scheme is not suitable for incorporation with the 
current protocol implementation for the ARPA Network, it is a 
document worthy of study for possible application to future 
protocol efforts. 
------------------------------<page break>-----------------------------
 Security Classification 
(Security classilicatzon of title, body o[ ibsfrsct arid indexmt annotation nlu.wt be entered when the overall report i. cl,'ssilied) 
b. GOUP 
1. ORIGINATING ACTIVITY (Coworate author) 
Bolt Beranek and Newman Inc. 
50 Moulton Street 
gambride. Mass. 02138 
l.Jul.v 1970 to 30 September lq70 
4. DESCRIPTIVE NOTES (Type o[ report and, inclusive dates.) 
5. AUTHOR[S) (First name, middle initial, test name) 
Bolt Beranek and Newman Inc. 
October 1970 
DAHC 15-69-C-0179 
7h. NO. OF REFS 
OTHER REPORT NOIS) (Any other numbers that may be assigned 
this report) 
Advanced Research Projects Agency 
Washington, D. C. 20301 
The ba'sic function of the IMP computer network is to allow large exist- 
ing time-shared (Host) computers with different system configurations to 
communicate with each other. Each IMP (Interface Message Processor) 
computer accepts messages for its Host from other Host computers and 
transmits messages from it Host to other Hosts. Since there will not 
always be a direct link between two Hosts that wish to communicate, 
individual IMPs will, from time to time, perform the function of trans- 
ferring a message between Hosts that are not directly connected. This 
then leads to the two basic IMP configurations -- interfacing between 
Host computers and acting as a message switcher in the IMP network. 
The message switching is performed as a store and forward operation. 
Each IMP adapts its message routine to the condition of those portions 
of the IMP network to which it is connected. iMPs regularly measure 
network performance and report in special messages to the network 
measurement center. Provision of a tracing capability permits the net 
operation to be studied comprehensively. An automatic trouble reporting 
capa0ility detects a variety of network difficulties and reports them 
to an interested Host. An IMP can throw away packets that it has receiv- 
ed but not yet acknowledged, transmitting packets to other IMPs at its 
own discretion'. Self-contained network operation is designed to protect 
and deliver messages from the source Host to the destination IMP. 
D D,%"t.14 7 3 
$/N O101~807~681 
(PAGE 1 ) 
Security Classification 
------------------------------<page break>-----------------------------